Create Your First Data Services
This page last changed on Jan 13, 2009.
Oracle Data Service Integrator Documentation > Data Services Developer's Guide How To Create Your First Data ServicesCreating a data service from scratch — as you will if you follow this tutorial — is a good way to get the feel of working with Workshop for WebLogic, as well as other aspects of data services. In the process a logical data service you will also automatically create several physical data services. Physical data services represent physical data sources. Topics
Goal of the TutorialThe goal of this tutorial is to illustrate an approach to creating a logical data service, including creating an XML Type (schema), using Workshop for WebLogic. Along the way you will use many of the facilities:
This example uses data provided with the Retail Dataspace Sample Application (RTLApp). RequirementsThe requirement for the demonstration project are to develop a logical data service from several physical data services. When run by a client, the data service will return a consolidated view of a particular customer's orders, as well as all the items in each order. Before You BeginBefore you can begin the tutorial make sure you:
Oracle Data Service Integrator Default Perspective After Adding myDataspace
Creating a Dataspace ProjectData services are created within Workshop for WebLogic as Eclipse projects, called dataspace projects. With the Oracle Data Service Integrator-enabled server running, the first step is to create a new dataspace project.
Creating a New Dataspace ProjectSet Up a Folder for Physical Data ServicesData services are typically created inside project folders. The recommended first step in creating one or several data services is to create containers (folders).
Creating Physical Data ServicesPhysical data services are based on existing data sources. Whenever you create physical data services, you must first identify the data source. Available options include:
To take advantage of data provided with the sample application, a relational data source is used. The sample databases RTLAPPLOMS and RTLCUSTOMER provided with the Retail Sample Application contain five tables. In this section you will create physical data services corresponding to those tables. Data Sources and Data Services
Select a Data SourceThe select a data source dialog initially allows you to select a data source type (such as relational or web service). Once that selection is made, additional options appears. The following table lists the actions required to select the relational data sources that will be used throughout this tutorial.
Setting Up Sources for Data Services
Your new data services appear in your physical folder in the Project Explorer. Newly Created Data ServicesIf you expand your new data services you will see that each physical data service has been created with functions corresponding to standard relational operations. For example the CUSTOMER.ds data service contains the following operations:
Schemas DirectoryYou should find a schemas folder adjacent to the newly created data services. This folders contains schema files created during the metadata import process. For relational sources, schemas are created for both the data source (table or view) and the primary keys found during the introspection of the relational source. For example:
If you look in the schemas directory you will see that for each physical data service created, two schemas were created. One representing the physical data service and the other to describe the primary keys in the data source. Expanded View of Project ExplorerWhen a logical entity data service is created, it is either:
Publish Your ProjectsUsing Workshop for WebLogic, you can publish your dataspace projects to a server when it is ready for testing and debugging. Publishing is also useful during the project development phase because in its default configuration, when you publish a project in Workshop for WebLogic, it is automatically built and validated. The validation process identifies error conditions, if any. Note: When publishing a project to a server, the project is validated and only valid projects are successfully published. To publish your projects:
A dialog displays the progress and, upon successful completion, the status of the server changes to Synchronized.
Creating a Logical Data ServiceA logical data service can be thought of as a "virtual" data source. Logical data services are built upon existing physical or logical data services.
To create a logical data service:
After making these selections, your new entity data service appears in Overview mode. Since no functions have yet been added to your data service, the work area of the data service is empty. Options available for creating and testing your new data service appear at the bottom of the workspace. In addition to Overview, you will see the following tabs:
Attempt To Publish Your Dataspace ProjectThere are times when attempts to publish your data service under development will not be successful. This is expected since as you create your query in the Query Map, source is created simultaneously. (When a data service is in such a state, you will notice a red x on its associated icon in Project Explorer.) Project After Unsuccessful Publish Effort
Incomplete Logical Data Service Validation Error
Bottom Up or Top DownData services can be designed from the top-down or bottom-up. The following table compares these two approaches. Data Services Design Models
This tutorial uses a bottom-up design. Add an Operation to CUST_ORDERS_ITEMSThe next step is to add a read function to your new data service that will return a document containing all the orders placed by a particular customer, and all the items in each order. To add your new function:
Creating a New OperationThe next steps will create a publicly available Read function for your new data service. Add Operation Dialog Options
Add Operation Dialog
New Data Service Operation and PropertiesBuilding Your QueryClick on the custOrdersItemsByLastName function name in the work area to enter Query Map mode. Initial Query View
Building Your FLWR Statement GraphicallyXQueries are often described as being build upon "FLWR" statements:
Adding Data Sources to Query View - the For/Let StatementsIt is through the Query Map that you can bring together representations of existing data sources and associate their elements with the Return type of a new data service. In the current example your new data service is to provide a consolidated view drawn from the CUSTOMER, CUSTOMER_ORDER, and CUSTOMER_ORDER_LINE_ITEM data services. The Read functions from these physical data services therefore need to be represented in the work area of the new data service. Follow these steps to add these representations to your Query map:
Each of these operational building blocks will become for statements in the XQuery description of your new data service. Data Source Representations in Work AreaThe Data Source Representations in Work Area graphic shows the artifacts useful in tailoring your query:
Add a ParameterParameters can be added when your operation is created or in the Query Map. Parameters can be of simple (primitive) type or complex, such as the XMLtype from another data service. In this case you create a single xs:string parameter that will allow retrieval of one or more records by a customer's last name.
To add a parameter:
Edit Function Signature Dialog Options
Add New Parameter DialogThe last_name parameter appears in the work area.
Partial Source of CUST_ORDERS_ITEMS After Addition of Read Functions and last_name Parameterxquery version "1.0" encoding "UTF-8"; (:: pragma ... ::) declare namespace cus2= "ld:physical/CUSTOMER"; declare namespace cus1= "ld:physical/CUSTOMER_ORDER"; declare namespace ust= "custOrdersItems"; declare namespace cus= "ld:physical/CUSTOMER_ORDER_LINE_ITEM"; declare namespace tns="ld:logical/CUST_ORDERS_ITEMS"; (:: pragma ... ::) declare function tns:custOrdersItemsByLastName(){ for $CUSTOMER in cus:CUSTOMER() for $CUSTOMER_ORDER in cus1:CUSTOMER_ORDER() for $CUSTOMER_ORDER_LINE_ITEM in cus2:CUSTOMER_ORDER_LINE_ITEM() return () }; Map Elements to the Return TypeThree icons associated with projecting elements to the Return type appear above the Query Map work area. (You may need to widen your window to see all three icons.) Mapping Mode Icons
You will use these options to map representations of source data to the Return type of your new data service. Populating the Return Clause
Adding Child Elements to Return TypeSet Statement ScopingClick the Source tab to inspect your generated code. Notice that the Return type contains all three For: statements. Function cust_orders_items_byLastName(string) in Source Viewdeclare function tns:custOrdersItemsByLastName($last_name as xs:string) { for $CUSTOMER in cus:CUSTOMER() for $CUSTOMER_ORDER in cus1:CUSTOMER_ORDER() for $CUSTOMER_ORDER_LINE_ITEM in cus2:CUSTOMER_ORDER_LINE_ITEM() return <ust:CUSTOMER> <CUSTOMER_ID>{fn:data($CUSTOMER/CUSTOMER_ID)}</CUSTOMER_ID> <FIRST_NAME>{fn:data($CUSTOMER/FIRST_NAME)}</FIRST_NAME> <LAST_NAME>{fn:data($CUSTOMER/LAST_NAME)}</LAST_NAME> <CUSTOMER_SINCE>{fn:data($CUSTOMER/CUSTOMER_SINCE)}</CUSTOMER_SINCE> <EMAIL_ADDRESS>{fn:data($CUSTOMER/EMAIL_ADDRESS)}</EMAIL_ADDRESS> <TELEPHONE_NUMBER>{fn:data($CUSTOMER/TELEPHONE_NUMBER)}</TELEPHONE_NUMBER> <SSN?>{fn:data($CUSTOMER/SSN)}</SSN> <BIRTH_DAY?>{fn:data($CUSTOMER/BIRTH_DAY)}</BIRTH_DAY> <DEFAULT_SHIP_METHOD?>{fn:data($CUSTOMER/DEFAULT_SHIP_METHOD)}</DEFAULT_SHIP_METHOD> <EMAIL_NOTIFICATION?>{fn:data($CUSTOMER/EMAIL_NOTIFICATION)}</EMAIL_NOTIFICATION> <NEWS_LETTTER?>{fn:data($CUSTOMER/NEWS_LETTTER)}</NEWS_LETTTER> <ONLINE_STATEMENT?>{fn:data($CUSTOMER/ONLINE_STATEMENT)}</ONLINE_STATEMENT> <LOGIN_ID?>{fn:data($CUSTOMER/LOGIN_ID)}</LOGIN_ID> { <ust:CUSTOMER_ORDER> <ORDER_ID>{fn:data($CUSTOMER_ORDER/ORDER_ID)}</ORDER_ID> <C_ID>{fn:data($CUSTOMER_ORDER/C_ID)}</C_ID> <ORDER_DT>{fn:data($CUSTOMER_ORDER/ORDER_DT)}</ORDER_DT> <SHIP_METHOD_DSC>{fn:data($CUSTOMER_ORDER/SHIP_METHOD_DSC)}</SHIP_METHOD_DSC> <HANDLING_CHRG_AMT>{fn:data($CUSTOMER_ORDER/HANDLING_CHRG_AMT)}</HANDLING_CHRG_AMT> <SUBTOTAL_AMT>{fn:data($CUSTOMER_ORDER/SUBTOTAL_AMT)}</SUBTOTAL_AMT> <TOTAL_ORDER_AMT>{fn:data($CUSTOMER_ORDER/TOTAL_ORDER_AMT)}</TOTAL_ORDER_AMT> <SALE_TAX_AMT>{fn:data($CUSTOMER_ORDER/SALE_TAX_AMT)}</SALE_TAX_AMT> <SHIP_TO_ID>{fn:data($CUSTOMER_ORDER/SHIP_TO_ID)}</SHIP_TO_ID> <SHIP_TO_NM>{fn:data($CUSTOMER_ORDER/SHIP_TO_NM)}</SHIP_TO_NM> <BILL_TO_ID>{fn:data($CUSTOMER_ORDER/BILL_TO_ID)}</BILL_TO_ID> <ESTIMATED_SHIP_DT>{fn:data($CUSTOMER_ORDER/ESTIMATED_SHIP_DT)}</ESTIMATED_SHIP_DT> <STATUS>{fn:data($CUSTOMER_ORDER/STATUS)}</STATUS> <TRACKING_NO?>{fn:data($CUSTOMER_ORDER/TRACKING_NO)}</TRACKING_NO> <DATE_INT?>{fn:data($CUSTOMER_ORDER/DATE_INT)}</DATE_INT> { <ust:CUSTOMER_ORDER_LINE_ITEM> <LINE_ID>{fn:data($CUSTOMER_ORDER_LINE_ITEM/LINE_ID)}</LINE_ID> <ORDER_ID>{fn:data($CUSTOMER_ORDER_LINE_ITEM/ORDER_ID)}</ORDER_ID> <PROD_ID>{fn:data($CUSTOMER_ORDER_LINE_ITEM/PROD_ID)}</PROD_ID> <PROD_DSC>{fn:data($CUSTOMER_ORDER_LINE_ITEM/PROD_DSC)}</PROD_DSC> <QUANTITY>{fn:data($CUSTOMER_ORDER_LINE_ITEM/QUANTITY)}</QUANTITY> <PRICE>{fn:data($CUSTOMER_ORDER_LINE_ITEM/PRICE)}</PRICE> <STATUS>{fn:data($CUSTOMER_ORDER_LINE_ITEM/STATUS)}</STATUS> </ust:CUSTOMER_ORDER_LINE_ITEM> } </ust:CUSTOMER_ORDER> } </ust:CUSTOMER> };
Using the Query Map you can adjust this quite easily by changing the scoping of the subordinate data services in the Return type, as shown in the following steps. Adjusting Scoping Rules in the Return Type
Nested Zoning in the Return TypeSwitch to Source view to verify that the for statements are nested in the Return clause. Now, when a parameter is passed with the operation, all the customers with a particular last name will be returned which contains orders and order line items associated with that customer. Source View of Return Type with Nested Return Typesdeclare function tns:custOrdersItemsByLastName($last_name as xs:string) { for $CUSTOMER in cus:CUSTOMER() return <ust:CUSTOMER> <CUSTOMER_ID>{fn:data($CUSTOMER/CUSTOMER_ID)}</CUSTOMER_ID> <FIRST_NAME>{fn:data($CUSTOMER/FIRST_NAME)}</FIRST_NAME> <LAST_NAME>{fn:data($CUSTOMER/LAST_NAME)}</LAST_NAME> <CUSTOMER_SINCE>{fn:data($CUSTOMER/CUSTOMER_SINCE)}</CUSTOMER_SINCE> <EMAIL_ADDRESS>{fn:data($CUSTOMER/EMAIL_ADDRESS)}</EMAIL_ADDRESS> <TELEPHONE_NUMBER>{fn:data($CUSTOMER/TELEPHONE_NUMBER)}</TELEPHONE_NUMBER> <SSN?>{fn:data($CUSTOMER/SSN)}</SSN> <BIRTH_DAY?>{fn:data($CUSTOMER/BIRTH_DAY)}</BIRTH_DAY> <DEFAULT_SHIP_METHOD?>{fn:data($CUSTOMER/DEFAULT_SHIP_METHOD)}</DEFAULT_SHIP_METHOD> <EMAIL_NOTIFICATION?>{fn:data($CUSTOMER/EMAIL_NOTIFICATION)}</EMAIL_NOTIFICATION> <NEWS_LETTTER?>{fn:data($CUSTOMER/NEWS_LETTTER)}</NEWS_LETTTER> <ONLINE_STATEMENT?>{fn:data($CUSTOMER/ONLINE_STATEMENT)}</ONLINE_STATEMENT> <LOGIN_ID?>{fn:data($CUSTOMER/LOGIN_ID)}</LOGIN_ID> { for $CUSTOMER_ORDER in cus1:CUSTOMER_ORDER() return <ust:CUSTOMER_ORDER> <ORDER_ID>{fn:data($CUSTOMER_ORDER/ORDER_ID)}</ORDER_ID> <C_ID>{fn:data($CUSTOMER_ORDER/C_ID)}</C_ID> <ORDER_DT>{fn:data($CUSTOMER_ORDER/ORDER_DT)}</ORDER_DT> <SHIP_METHOD_DSC>{fn:data($CUSTOMER_ORDER/SHIP_METHOD_DSC)}</SHIP_METHOD_DSC> <HANDLING_CHRG_AMT>{fn:data($CUSTOMER_ORDER/HANDLING_CHRG_AMT)}</HANDLING_CHRG_AMT> <SUBTOTAL_AMT>{fn:data($CUSTOMER_ORDER/SUBTOTAL_AMT)}</SUBTOTAL_AMT> <TOTAL_ORDER_AMT>{fn:data($CUSTOMER_ORDER/TOTAL_ORDER_AMT)}</TOTAL_ORDER_AMT> <SALE_TAX_AMT>{fn:data($CUSTOMER_ORDER/SALE_TAX_AMT)}</SALE_TAX_AMT> <SHIP_TO_ID>{fn:data($CUSTOMER_ORDER/SHIP_TO_ID)}</SHIP_TO_ID> <SHIP_TO_NM>{fn:data($CUSTOMER_ORDER/SHIP_TO_NM)}</SHIP_TO_NM> <BILL_TO_ID>{fn:data($CUSTOMER_ORDER/BILL_TO_ID)}</BILL_TO_ID> <ESTIMATED_SHIP_DT>{fn:data($CUSTOMER_ORDER/ESTIMATED_SHIP_DT)}</ESTIMATED_SHIP_DT> <STATUS>{fn:data($CUSTOMER_ORDER/STATUS)}</STATUS> <TRACKING_NO?>{fn:data($CUSTOMER_ORDER/TRACKING_NO)}</TRACKING_NO> <DATE_INT?>{fn:data($CUSTOMER_ORDER/DATE_INT)}</DATE_INT> { for $CUSTOMER_ORDER_LINE_ITEM in cus2:CUSTOMER_ORDER_LINE_ITEM() return <ust:CUSTOMER_ORDER_LINE_ITEM> <LINE_ID>{fn:data($CUSTOMER_ORDER_LINE_ITEM/LINE_ID)}</LINE_ID> <ORDER_ID>{fn:data($CUSTOMER_ORDER_LINE_ITEM/ORDER_ID)}</ORDER_ID> <PROD_ID>{fn:data($CUSTOMER_ORDER_LINE_ITEM/PROD_ID)}</PROD_ID> <PROD_DSC>{fn:data($CUSTOMER_ORDER_LINE_ITEM/PROD_DSC)}</PROD_DSC> <QUANTITY>{fn:data($CUSTOMER_ORDER_LINE_ITEM/QUANTITY)}</QUANTITY> <PRICE>{fn:data($CUSTOMER_ORDER_LINE_ITEM/PRICE)}</PRICE> <STATUS>{fn:data($CUSTOMER_ORDER_LINE_ITEM/STATUS)}</STATUS> </ust:CUSTOMER_ORDER_LINE_ITEM> } </ust:CUSTOMER_ORDER> } </ust:CUSTOMER> }; Creating Joins - the Where ClausesWhere clauses satisfy either specific conditions (such as where $i=5) or join conditions such as: where $CUSTOMER_ORDER/ORDER_ID eq $CUSTOMER_ORDER_LINE_ITEM/ORDER_ID
Setting Up a Join ConditionYou can verify your first join clause by clicking on target (CUSTOMER_ORDER) object. Alternatively, you can look in Source view to verify that the new where clause is modifying the CUSTOMER_ORDER_LINE_ITEM type.
for $CUSTOMER_ORDER in cus1:CUSTOMER_ORDER() where $CUSTOMER/CUSTOMER_ID eq $CUSTOMER_ORDER/C_ID return Associate a Parameter with a For NodeAn additional necessary where condition that directs the query results to a particular customer can be created by adding a parameter to an element in a node. Parameters can be simple or complex. This project requires use of a single parameter: last_name.
A line connecting the parameter to the node will appear. This will also be reflected in the Query Map Expression editor when you click on the CUSTOMER For: node. Mapped Parameter and Where ClauseThe results of this operation can also be viewed in the Source tab. declare function tns:custOrdersItemsByLastName($last_name as xs:string) as element(ust1:CUST_ORDERS_ITEMS)* { for $CUSTOMER in cus:CUSTOMER() where $last_name eq $CUSTOMER/LAST_NAME return ... In Source you will also notice that the for statements now contain where clauses based on your graphical gestures. for $CUSTOMER in cus:CUSTOMER() where $last_name eq $CUSTOMER/LAST_NAME return ... for $CUSTOMER_ORDER in cus1:CUSTOMER_ORDER() where $CUSTOMER/CUSTOMER_ID eq $CUSTOMER_ORDER/C_ID return ... for $CUSTOMER_ORDER_LINE_ITEM in cus2:CUSTOMER_ORDER_LINE_ITEM() where $CUSTOMER_ORDER/ORDER_ID eq $CUSTOMER_ORDER_LINE_ITEM/ORDER_ID return ... Creating, Saving, and Associating the XML TypeSince this entity data service is being created "bottom up", it is not yet associated with an XML Type (schema). Now that you have a Return type, however, you create a valid XML Type by saving your Return type and associating it with a namespace that is unique to the project.
Modifying the XML TypeWhen an XML Type is generated, complex elements by default return a single instance of their type (for example, one CUSTOMER_ORDER will be returned even if there are many). In order to return all customer orders and all of each orders' line items minor changes to the data service's XML type are needed. The XML markup for this is: maxOccurs="unbounded" In other words, the element returns "n", any number of document fragments that meet the criteria. To modify your new CUST_ORDERS_ITEMS XML Type:
CUST_ORDERS_ITEMS Schema (XSD File)<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="custOrdersItems" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="CUST_ORDERS_ITEMS"> <xs:complexType> <xs:sequence> <xs:element name="CUSTOMER_ID" type="xs:string"/> <xs:element name="FIRST_NAME" type="xs:string"/> <xs:element name="LAST_NAME" type="xs:string"/> <xs:element name="CUSTOMER_SINCE" type="xs:date"/> <xs:element name="EMAIL_ADDRESS" type="xs:string"/> <xs:element name="TELEPHONE_NUMBER" type="xs:string"/> <xs:element name="SSN" maxOccurs="1" minOccurs="0" type="xs:string"/> <xs:element name="BIRTH_DAY" maxOccurs="1" minOccurs="0" type="xs:date"/> <xs:element name="DEFAULT_SHIP_METHOD" maxOccurs="1" minOccurs="0" type="xs:string"/> <xs:element name="EMAIL_NOTIFICATION" maxOccurs="1" minOccurs="0" type="xs:short"/> <xs:element name="NEWS_LETTTER" maxOccurs="1" minOccurs="0" type="xs:short"/> <xs:element name="ONLINE_STATEMENT" maxOccurs="1" minOccurs="0" type="xs:short"/> <xs:element name="LOGIN_ID" maxOccurs="1" minOccurs="0" type="xs:string"/> <xs:element form="qualified" name="CUSTOMER_ORDER" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="ORDER_ID" type="xs:string"/> <xs:element name="C_ID" type="xs:string"/> <xs:element name="ORDER_DT" type="xs:date"/> <xs:element name="SHIP_METHOD_DSC" type="xs:string"/> <xs:element name="HANDLING_CHRG_AMT" type="xs:decimal"/> <xs:element name="SUBTOTAL_AMT" type="xs:decimal"/> <xs:element name="TOTAL_ORDER_AMT" type="xs:decimal"/> <xs:element name="SALE_TAX_AMT" type="xs:decimal"/> <xs:element name="SHIP_TO_ID" type="xs:string"/> <xs:element name="SHIP_TO_NM" type="xs:string"/> <xs:element name="BILL_TO_ID" type="xs:string"/> <xs:element name="ESTIMATED_SHIP_DT" type="xs:date"/> <xs:element name="STATUS" type="xs:string"/> <xs:element name="TRACKING_NO" maxOccurs="1" minOccurs="0" type="xs:string"/> <xs:element name="DATE_INT" maxOccurs="1" minOccurs="0" type="xs:long"/> <xs:element form="qualified" name="CUSTOMER_ORDER_LINE_ITEM" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="LINE_ID" type="xs:string"/> <xs:element name="ORDER_ID" type="xs:string"/> <xs:element name="PROD_ID" type="xs:string"/> <xs:element name="PROD_DSC" type="xs:string"/> <xs:element name="QUANTITY" type="xs:integer"/> <xs:element name="PRICE" type="xs:decimal"/> <xs:element name="STATUS" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> Testing Your Data Service FunctionHaving created a parameterized read function for your logical data service, you can now test it.
Testing a Parameterized QueryView Test Run ResultsTest results from this function can be viewed in two ways:
Test Run Results in Tree Style FormatReview Test Run InformationWhen a query is run in the Test editor, you will often be able to access information on your query's performance and the generated SQL (in the case of relational data). Even if a test is unsuccessful, the attempted execution may generate useful audit event statistics. Query Statistics in the Console WindowThe Console window will always contain information on a successfully executed query. Access the Console with: Window > Show View > Other... > General > Console Sample console output is shown below. Query Details in the Console WindowAdding Create-Update-Delete Functions to Your Data ServiceYou can also edit results in the Test area. In other words, you can update your data. To do this an update procedure based on your data service must exist. Until then, the Edit, Submit and Cancel buttons at the bottom of the Test mode work area ( ) will be grayed out. The easiest way to create an update procedure for your logical data service is to generate a default update map procedure. When you do this you will also be given the option of creating delete and insert procedures. To add the new procedures:
Notice that the procedures are added to your data service. Update Map ProceduresUpdating Your ResultsNow that you have an updateCUST_ORDERS_ITEMS procedure, you can update data -- either through the Test tab or through authorized client applications. Here are the steps:
Reviewing the Query PlanAfter a data service has been successfully published, the query plan for the service's read functions can be examined through the Plan tab. The plan can be display in tree or text mode.
Tree View of Query PlanReviewing the Update MapAfter an entity data service is successfully published and contains an update function, its update map can be inspected and, as necessary, edited.
CUST_ORDERS_ITEMS Update Map
Archiving Your ProjectYou can save your entire project to a ZIP file. Then, when you need to load it again, you can do so with a simple Import operation.
Creating the Archive FileA file myDataspace.zip will be created in the directory you specified. SummaryCongratulations! In just a few minutes you have:
About 150 lines of XQuery have been generated. |
Document generated by Confluence on Jan 13, 2009 15:57 |